Francisco IBS

Boa Tarde... Compactei toda a pasta do bloco X que esta em anexo. Primeira mente criei a unit "pcnGeradorBlocoX.pas" que é uma cópia da "pcnGerador.pas" só que modifiquei a classe para usar WideString e TFileStream pois não queria estragar nenhuma outra rotina que já usa ele. Por que "TFileStream" ? Nos testes que fiz foi a forma mais rápida que consegui para criar o arquivo. Unit ACBrBlocoX_WebServices.pas ganhou 2 novas variaveis "SituacaoProcStr" e "Mensagem" para guardar as informações do retorno. Acredito que seja isso, desculpe a demora, como comentei não estou na empresa essa semana. Caso falte algo ou alguem tenha alguma outra sugestão fico aberto a críticas. ACBrBlocoX.rar

Inicialmente quando fiz as alterações tinha uma esperança e pelas conversas no forum que isso seria alterado, mais pelo andar da carruagem creio ser dificil, então por isso não sugeri a alteração no SVN. Não sei como anda o desenvolvimento disso pelos ADM's ou colaboradores que tem acesso ao SVN mais se não tem nenhuma alteração do fonte para isso posso disponibilizar 100problemas o que desenvolvi, só não consigo essa semana só para semana que vem.

Esse foi o entendimento que tive, a única coisa que eu mudaria no que vc falou é a questão de produto com quantidade < 0... pelo que da a entender isso não pode ocorrer, não recordo se vi algum questionamento disso lá no grupo de discussão ou na base de conhecimento do CAF, no endereço http://caf2.sef.sc.gov.br/, acesse a opção ECF, vais encontrar algo, pelo que entendi o cliente deve sempre deixar o estoque 0 ou positivo, no arquivo não deve conter estoque negativo. O que é estranho pq lembro de ter uma flag no xml que diz se o estoque é positivo ou negativo.

Boa Tarde... Semana passada troquei um e-mail com o Bruno Nogueira sobre isso, eu tive um primeiro entendimento errado o correto é: - Qualquer produto com quantidade a cima de 0. - Qualquer produto com movimentação, venda ou entrada. Deve constar no arquivo de estoque.

O componente estava na tela mais não estava selecionado no componente do sat.

Boa Tarde João... Então e tomei a liberdade de fazer algumas alterações no componente para gerar o arquivo já que o estoque já é obrigatório o envio esse mês, precisei alterar a forma que se guardava a informação para gerar o XML(esta usando String se não me engano) e também alterei a forma de se fazer a assinatura, pode se por falta de conhecimento minha do componente mais estava levando bastante tempo. Notei que vc comentou de possuir 120k de produtos, a legislação esta bem "por cima" dando/deixando muitas brechas pela questão do entendimento, pelo que entendi deram liberdade para cada estado criar o seu WS então pensa na confusão que isso vai ficar... Mais em contato com o pessoal técnico que me colocou em contato com o GESAC cosegui esclarecer bastante coisas uma delas é que não é necessário mandar todos os produtos(como me foi exigido na homologação) e sim apenas os que tiveram movimentação(entradas ou saidas) no período. Vou deixar um grupo de discussão administrado pela SEF-SC bem util a baixo, anteriormente deixavam até fazer questionamentos mais hj apenas para atualização de o que esta ocorrendo na parte Técnica do Bloco X. Mais tem algum material de legislação ali já postado tbm: https://groups.google.com/forum/#!forum/sef-sc-siv Nesse grupo de discussão vc vai poder ver que existem questionamentos com relação ao tamanho do arquivo e o pessoal da SEF não parece ter a intenção nenhuma de mudar isso ou a forma que é feita, não que devemos concordar com isso, mais precisamos cumprir as obrigações legais que nos são impostas.

Daniel acho que podemos fechar o Tópico, já saio bastante assunto fora dele mesmo e o que precisava já foi esclarecido: - Rejeição 905 estaria ocorrendo pela falta da tag vDesc no XML. - Essa tag não será gerada caso o valor for 0 já que não é um campo obrigatório. - Esse valor não vai ser alterado no componente pois o mesmo respeita as NT.

Grande chance da SEFAZ não ter atualizado as alterações da NT, por isso vc não estaria tendo a rejeição 905.

Blz @BigWings, pelo que entendi no seu primeiro post: A sugestão seria jogar um 0,01 no valor desconto para que ele seja inserido no XML, certo? R: Alguem do ACBr sabe ou tem algum contato/colaborador que chegou a confirmar se essa validação esta correta(por algum contato com alguma das SEFAZ), já que isso seria um paliativo certo? PS: Particularmente achei mais bonito por o campo como obrigatório no fonte indo 0,00, sei que vou ter que dar manutenção nisso caso ocorra alguma alteração na unit, mas preferi assim. Ao menos até desvendarmos o como isso vai ficar.

Bem ai que esta o problema já que a nota técnica vai de contra a isso, então não da de saber se é um erro deles ou um erro na NT. Como traz a NT 1.60 não obriga nenhum dos campos do "Grupo Fatura", a Regra "Y01-20" meio que vai de contra ao que esta na descriminação do campo... Agora ficamos nessa de se o Estagiário lá só seguio ao pé da letra o que estava descrito na regra ou se esqueceram de alterar a descrição do campo.

Desculpe Wallas, estava testando aqui e tinha alterado o fonte colocando obrigatório o campo, justamente por não ter desconto e quando informado 0 no valor ele não gerava no XML. "Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 1, nfe.Cobr.Fat.vDesc, DSC_VDESC);" Então creio que terá que ser tratado diferente esse campo, para mesmo que for 0 ir no XML.

Bom Dia... Realizei uns testes hj pela manha no ambiente de homologação de SC e obtive a rejeição: "905 - Rejeicao: Campos do grupo Fatura nao informados" Indo no site do SEFAZ notei que foi disponibilizado um novo pacote de SCHEMAS onde alteram a TAG vDesc, fica a dica pra quem encontrar o mesmo problema e o pedido para atualizaram no SVN. Esquemas XML NF-e - Pacote de Liberação No. 9 (Novo leiaute da NF-e, NT 2016.002 v.1.60 - b) http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=CoNA9VIgZ3E=

Estranho gerei algo como imagino que vc tentou e deu certo enviando para SC? 42180572378391000193554000000006601538804287-nfe-Proc(NFe.660).xml

Bom Dia... Tente criar 1 "detPag" para cada "dup" que vc criou, deve validar.

Pois então, algum problema tinha, mais hj de manhã estava funcionando td corretamente como o esperado. Testes feitos apenas para SC.

Seguindo a dica de @vinicius keller parou de ocorrer o erro em nDup mais não validou dando outra rejeição, então entrei em contato com CAF que retornaram o seguinte: Boa Tarde... Estou tentando validar uma Nota no Layout 4.0 e estou recebendo o seguinte rejeição: 857 - Rejeicao: Numero da parcela invalido ou nao informado Pelo que da a entender essa tag nDup - Número da Parcela, seria a sequencia da parcela para o documento? É um erro na estrutura do XML ou algo do WS? Resposta Prezado Francisco O erro é devido ao fato da SVRS ainda não ter implantado a Nota Técnica 218.002 na versão 1.50, a previsão é para a implantação em homologação entrar amanha (16/05), é para produção deve ser estendido o prazo para 28/05. Favor aguardar a implantação para efetuar novo teste em homologação. Então o negócio é esperar pra testarmos amanhã.

Testes feitos em SC 04/05/2018 as 08:00 ainda não estava com o WS Homologação atualizado, se mantem o retorno de rejeição 867.

Obrigado pelo retorno Daniel, agora então ficamos na mão do SEFAZ.

Boa Tarde @José Carlos Buss saberia me informar se compilando em 64bits lhe resolveu o problema, se sim qual o tamanho do arquivo/quantidade de itens que chegou a testar? @Daniel Simoes vc comentou anteriormente que não é possível fazer fazer isso da forma atual que o ACBr trata/processa o arquivo para assinar, certo? Pensam em fazer alguma alteração, ou devido a questão do tamanho do arquivo irão aguardar que o estado altere a rotina? Poderias sugerir alguma outra forma de fazer isso?

O integrador estava no projeto apenas não estava associado, associei e passou a funcionar, fica a dica e a sugestão para ajuste no svn.

Alguém está conseguindo usar o exemplo delphi? O erro reportado pelo EvandroMira tbm ocorreu aqui e fui testar as funções da aba MFE e os 4 botões estão me gerando um acesso violento(talvez devido ao primeiro erro).

Obrigado Tulio, estava com o mesmo problema e já tinha baixado do git e do SVN umas 5 vezes deletando td e recarregando e não tinha dado certo, fazendo o Uninstall do pacote funcionou.

Bom Dia... Desculpe a demora, mas precisei testar novamente a rotina já que parou de funcionar, creio que alguma nota técnica ou atualização no WS possa ter corrigido a "falha" que deixava não enviar a tag "vPag", quando testei isso devíamos estar na "Nota Técnica 2016.002 - v1.30". Não utilizando as finalidades 3 e 4(Ajuste e Devolução) parece que é obrigado informar o valor do pagamento que é o que da a entender na NT. Não querendo incomodar mais @BigWings ou @Italo Jurisato Junior saberiam algo mais sobre isso? Dou o exemplo de uma nota de transferência não "existe" valor de pagamento e a finalidade da NFe pra esse caso não se encaixa no 3 ou 4, como tratar isso? Sei que não é culpa do ACBr mais questiono já que isso já esta em produção, como estão fazendo com esses casos? Transferencia.xml

Bom Dia... Você realizou a alteração que passei no inicio do post?

Note que o problema que comentei é no caso de vc estar utilizando "tPag = 90= Sem pagamento", vc postou um xml com vários tipos e formas de pagamento, não tem nada haver com a situação reportada no tópico.